[セッションレポート]サステナブルでハイパフォーマンスなアーキテクチャの実現 (SUS303) #reInvent

AWS認定トレーニング講師の平野@おんせん県おおいたです。

今日は「Delivering sustainable, high-performing architectures」というタイトルのセッションについてレポートします。

セッション紹介

今日のビルダーは、ワークロードが二酸化炭素に与える影響を以前にも増して意識しています。このセッションでは、リソースの使用量を削減しながらパフォーマンスを最適化するのに役立つアーキテクチャ設計とツールについて深く掘り下げます。また、これらの改善を測定するためのダッシュボードを紹介します。また、AWS CUDOSダッシュボードのようなツールが、持続可能性、パフォーマンス、コストを最適化するための意思決定にどのように役立つかについても説明します。

オンデマンド動画

概要

AWSをサステナビリティのパートナーに

AWSがテクノロジーパートナーとして、クラウドにおけるサステナビリティの目標達成をどのように支援できるかを説明します。AWSがどのように御社のサステナビリティの旅をお手伝いできるかをお話するためには、まず、サステナビリティのための共有責任モデルについて理解する必要があります。

この責任共有モデルに基づいて、AWSがサステナビリティの旅でお客様を支援できる主な方法は3つあります。

AWSへの移行

AWSのクラウドに移行することで、そのワークロードをオンプレミスのデータセンターで管理する場合と比較して、二酸化炭素排出量を削減することができます。

オンプレミスのデータセンターと比較して、AWSはお客様の二酸化炭素排出量を約80%削減でき、100%再生可能エネルギーで稼働している場合は最大96%まで削減できるとされています。AWSのインフラは、米国の企業データセンターの中央値よりも3.6倍、ヨーロッパの企業データセンターの平均よりも最大5倍、アジア太平洋地域のオンプレミスデータセンターの平均よりも5倍エネルギー効率が優れています。

トランスフォーム

お客様のニーズに応じて、当社のプロセス・サステナビリティ・プラクティスやパートナー・プログラムを通じて、サステナビリティのユースケースに対応したソリューションを構築し、お客様のビジネスを変革するお手伝いをすることも可能です。ほとんどすべての産業は、共通の課題を抱えています。これらは一般的に、設備管理、設計、最適化、そしてカーボントラッキングやフットプリントといったものを含みます。

多くのサステナビリティ・ソリューションは、外部データセットを必要とし、また外部データセットによって改善することもできます。サステナビリティのためのデータを提供する3つの主要なプログラムがあります。これらのプログラムと利用可能なデータセットを活用して、新しいクラウドネイティブのソリューションを開発し、持続可能性の目標に取り組むことができます。

ワークロードの最適化

持続可能で高性能なアーキテクチャを実現するためには、アーキテクチャに2つの重要な機能を設計し、実装する必要があります。

まず、アーティファクトはリソース効率に優れている必要があります。リソース効率とは、ビジネス要件を満たすために、アーキテクチャ内でクラウドのリソースを効率的に使用することです。そして、需要の変化や技術の進化に応じて、そのレベルの効率性を維持する必要があります。

また、需要の変化や技術の進化に応じて、アーキテクチャにも影響が及ぶはずです。つまり、新しいアーキテクチャを可視化し、リソースのフットプリントと利用状況を確認できるようにする必要があります。また、このデータを使って、ワークフローの炭素コストを削減するためにどのような技術が役立つかを評価することができます。

AWS Well-Architected

AWS Well-Architectedフレームワークは、AWS上の様々なアプリケーションやワークロードに対して、安全で高性能、そして効率的なインフラストラクチャを構築することを支援します。

昨年のre:Inventで6番目の柱としてサステナビリティを発表しました。サステナビリティの柱は、サステナビリティのベストプラクティスに対してアーキテクチャを一貫して測定し、改善すべき領域を特定する方法を提供することで、フレームワークを強化するものです。

サステナビリティの柱には、6つのフォーカスドメインがあります。地域の選択、ユーザーの行動、ソフトウェアとアーキテクチャ、ハードウェア、データ開発、そしてデプロイメントプロセスです。それでは、それぞれのフォーカス・ドメインについて説明します。

1 リージョンの選択

ワークロードのためのリージョンは、ビジネス要件と持続可能性の目標の両方に基づいて選択する必要があります。コンプライアンスコスト、さらには利用可能なサービスやリソース、機能といった要因が、ワークロードの候補となる地域を候補として挙げる際に重要な役割を果たします。もし、これらのビジネス上の要因が許すなら、Amazonの再生可能エネルギープロジェクトに近いリージョンや、より低い炭素強度のリージョンを採用することを考え始めることができます。

2 ユーザーの行動パターン

クラウドの弾力性や自動スケーリング機能を使って、常にリソースを適切なレベルで使用できるようにする必要があります。ユーザーが実行するアクティビティに合わせて最適化する必要があります。

私たちがお客様にお勧めするのは、SLAを見直して、インパクト・フレンドリーなSLAを交渉することです。ビジネス要件を満たすためにSLAを再定義するということです。つまり、品質の低下や応答時間の増加を許容する代わりに、二酸化炭素排出量や環境への影響を大幅に削減するトレードオフを行う必要があるのです。

3 ソフトウェアとアーキテクチャ

たとえば、使用しないコンポーネントを削除したり、データアクセスやデータストレージを最適にサポートするアーキテクチャパターンを使用したりすることなどが挙げられます。 重要なのは、同期ジョブやスケジュールジョブ（私たちはこれを持続可能なスケジューリングと呼んでいます）に対するアーキテクチャの最適化に注力することです。 例えば、需要にピークがあり、それによりワークロードが使用するリソースとエネルギーが大きくなっている場合は、メッセージキューを導入して需要管理をスムーズにするなどの対策が可能です。

4 ハードウェア

ハードウェアとそのエネルギー消費と利用を最適化する方法を検討します。AWSのGravitonベースのインスタンスを汎用的に利用することが可能です。また、ディープラーニングのような特殊なワークロードの場合は、特殊なハードウェアを活用するようにします。AWS Inferentia / AWS Trainiumはこのようなユースケースに最適化されています。 また、AWSは、適切なサイジングの機会を提供するAWS compute optimizerなどのツールをいくつか提供しており、それらを活用したレコメンデーションが可能です。

5 データ

データストレージとネットワーク上のデータ移動の最適化に焦点を当てる必要があります。それらのデータセットの保持を最適化するために、自動的なライフサイクル・ポリシーを導入し、不要なデータセット、不要なデータセットを削除する必要があります。さらに、データサイズとネットワーク上のデータ移動を最小限に抑えることができる戦略も検討する必要があります。また、すべてのデータをバックアップする必要はありません。影響があるかどうか、あるいはそれらのデータを再作成することが不可能であるかどうかを確認するだけです。

6 開発・デプロイプロセス

ワークロードの持続可能性を向上させることができるため、より多くの自動化を採用するようにすべきです。また、Dev、Test、Prodといった異なる環境を使用している場合は、それぞれの環境で適切な利用レベルを確保する必要があります。さらに、OSのライブラリやアプリケーションを最新の状態に保つこと。また、OSのライブラリやアプリケーションを最新の状態に保つことも、ワークロード全体の効率を高め、効率的な機能や技術の採用を容易にするための重要な要素です。

改善プロセス

サステナビリティの柱で説明されている改善プロセスは、私たちが何十年もコストとパフォーマンスの改善を行っているのと同じように、繰り返し行われるプロセスである。例えば、ワークロードのリソース効率をX%向上させるというタスクがあるとします。これは、ワークフローの持続可能性を向上させるための目標です。

AWS customer carbon footprint tool

ワークロードのインパクトを認識し、効率的なパフォーマンスを実現するために利用できるツールを紹介します。 昨年のre:Inventで発表した、AWS customer carbon footprintです。tool。このツールは、お客様がAWS上で実行しているワークロードの二酸化炭素排出量を把握するためのもので、ツールを使って推定された実際の二酸化炭素排出量を報告し、お客様自身のレポートの中で使用できるサステナビリティ・レポートを示すことができます。

※参考リンク

AWS customer carbon footprintは、あなたが使っているサービスのポートフォリオ全体の二酸化炭素排出量を自動的に計算します。過去の二酸化炭素排出量を把握し、排出量の経時的な変化を確認することができます。

排出量の影響を進化させながら評価することができ、時間の経過とともに変化していく様子を見ることができます。複数のグラフが用意されているので、新たなトレンドとフットプリントを追跡することができます。

KPI

ワークロードの最適化としてプロキシメトリックを利用し、上記のようにサステナビリティKPIを比較可能にするために正規化します。

プロキシメトリック

プロキシメトリクスは、二酸化炭素排出量の方向性の改善を示す指標です。 リソースに着目し、どの方向にCO2排出量を削減するかを示すものです。そして、これはリリースごとに行うことができます。私たちは、純粋に3つの指標を見ることができます。ストレージ、コンピュート、そしてデータ転送です。

注意点として、1つの指標だけを最適化しようとしないことが重要です。なぜなら、指標は時に互いに競合するからです。リソース単体で見ればよいという落とし穴は避けなければなりません。

可視化

我々は評価し、可視化する必要があり、影響を認識し、リソースの最適化を行うことができます。目的は、チームレベルでKPIを含むダッシュボードを確立し、各チームが独自の目標を得て、独立して最適化に取り組むことができるようにすることです。

ワークフローの中で影響を認識することを素早く始める方法の1つは、Cloud intelligence dashboardを利用することです。すでに使っている人も多いかもしれません。これはセルフサービスで、うまく設計されたラボとして迅速に展開されます。通常は、実行済みのクラウドフォーメーションに対してだけです。ダッシュボードの多くは、特に関連性の高い情報を含んでおり、例えばGP 3のリソース使用状況や、gravitonへの移行状況などが表示されます。また、ロードバランスなど、意外と活用されていない項目も浮き彫りになります。

※参考リンク

Cloud intelligence dashboardはカスタマイズ可能で、例えば出力は6つのダッシュボードを選択できます。この技術のおかげで、カスタマイズできるフックがたくさんあります。CUDOSは最も人気のあるダッシュボードで、アイドル状態のNATゲートウェイなど、特にサステナビリティに優れた項目について包括的な詳細情報を提供してくれます。KPIやダッシュボードは非常に便利です。

Demo

最後にデモを行います。 このデモの主な目的は、改善プロセスを実証することです。レビューと改善目標の特定から、次のステップの評価を経て、この成功をどのように展開し再現するかについて示します。

まず、デモで利用するシステムの概要です

• AWS Glueを利用したデータ分析基盤です
• オープンソースのニューヨークのタクシー乗車データと、New York Open Data Registryから取得した地図データを分析します

Step 1: 持続可能性の目標からスタート

リソース使用率を少なくとも50％向上させることを目標に設定します

Step 2: 改善目標の確認と特定

私たちは持続可能性の柱に6つの重要な重点領域を持ち、グループワークアウトを改善するのに役立つ領域を特定するために、これらの重点領域を調査しました。探索の段階を経て、グループワークロードを改善するのに役立つ4つの領域を特定しました。

• ユーザーの行動パターン
  • オートスケーリングによるコンピュート利用率の向上
• データ
  • JOIN機構を変更し、データのシャッフルを削減
  • スキャンデータを減らすためにファイル形式を変更
• 開発・導入プロセス
  • Sparkのバージョンアップによる効率的な技術の採用

Step 3: 改善対象の優先順位付け

改善対象の優先順位付けのために、まずそれぞれを評価しました。

そして次のように優先順位付けしました。

1. Sparkのバージョンアップ
2. ファイルフォーマットの変更
3. オートスケーリングの使用
4. JOINメカニズムの変更

Step 4: 具体的な改善点を検証する

まずKPIの設定です。

先ほど示しましたこのKPIに従って、このデモでは、KPIを下記のように設定しました

それでは、先ほどの優先順位に従って、各シナリオの効果を検証します

シナリオ1：Sparkのバージョンをアップグレードする

Spark 2.4 から 3.1にアップグレードしました。

• 成果: 持続可能性KPIが20%低下
• 理由: Apache Spark 3の新機能により、クエリプランが動的に最適化されたため

シナリオ2：ファイルフォーマットの変更

ファイルフォーマットをCSVからParquetに変更しました

• 結果: サステナビリティKPIは、基本ケースと比較してさらに30%低下しました。
• 理由: メタデータを使用して必要なデータのみをスキャンし、適切な圧縮を行ったため。

シナリオ3：オートスケーリングを使用する

Glueのワーカーノードでオートスケーリングを使用するように変更しました

• 結果: サステナビリティKPIは、ベースケースに比べてさらに10%低下した
• 理由: AWS Glueのオートスケーリングは、リアルタイムにキャパシティを調整するため、アイドル状態のリソースを減らすことができるため。

シナリオ 4: JOIN メカニズムの変更

ソートマージJOINからブロードキャストJOINに変更

• ソートマージJOIN: 両方のデータセットが大きい場合、効率的
• ブロードキャストJOIN: 2つのデータセットのうちどちらかが小さい場合に効率的

• 結果: 持続可能性KPIは、基本ケースと比較してさらに30%低下
• 理由: JOINメカニズムの変更により、ワーカー間のネットワーク転送が最小化されたため

全体的な改善

4つの改善を通じて、KPIを90%削減することができました。これは当初の目標であった50%を上回るものです。そして、これらの改善目標はすべて、実環境に展開する可能性のあるKPIを改善するのに役立ちます。このように、私たちは、皆さんがお持ちの多くのワークロードと同じように、最新のデータアーキテクチャを使用しています。あなたの場合も、持続可能性を高めるために、同じようなプロセスを踏む必要があると思います。

主な成果

私たちは、アマゾンとAWSのサステナビリティの旅について、そして、私たち自身のサステナビリティの変革のために得た主要なイニシアチブについて話しました。また、アマゾンやAWSがどのようにテクノロジーパートナーになれるか、そしてサステナビリティの変革の旅をどのように支援できるかについてもお話しました。また、サステイナブルで高性能なアーキテクチャを実現するために役立つフレームワークやツールについても紹介しました。また、デモイベントを通じて、特定のワークロードをサステナビリティのためにどのように改善できるかを説明し、実演しました。

まとめ

持続可能性のあるシステム開発についてのセッションを紹介しました。ご興味があれば上記のリンクよりセッション動画をご覧ください。